X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C91DE1.32DDD9E0@onstor-exch02.onstor.net>; Tue, 23 Sep 2008 18:02:21 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: RMC RPC API
Date: Tue, 23 Sep 2008 18:02:21 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0BAC9158@onstor-exch02.onstor.net>
In-Reply-To: <20080923172220.1e32cd5f@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RMC RPC API
Thread-Index: Ackd25yuq3gKEWCBTI6t79OulZjTwQAAUpCQ
References: <BB375AF679D4A34E9CA8DFA650E2B04E0BAC8B1C@onstor-exch02.onstor.net> <20080923172220.1e32cd5f@ripper.onstor.net>
From: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>
Cc: "dl-Design Review" <dl-designreview@onstor.com>



>-----Original Message-----
>From: Andy Sharp
>Sent: Tuesday, September 23, 2008 5:22 PM
>To: Maxim Kozlovsky
>Cc: dl-Design Review
>Subject: Re: RMC RPC API
>
>On Mon, 22 Sep 2008 13:58:52 -0700 "Maxim Kozlovsky"
><maxim.kozlovsky@onstor.com> wrote:
>
>> Hello,
>>
>> Here is the design document for the rmc rpc api that was checked in
>> recently.
>>
>> Max
>>
>>  <<rmc-rpc-design.doc>>
>
>Well, this is a excellent step in the right direction for our software
>product, so I'm psyched to see this.
>
>
>
>Since this is ostensibly a high level API not dependent on RMC or any
>particular underlying protocol, can we change the naming to remove any
>mention of RMC from the API?  It would be nice to one day in the future
>be free of those three letters.  I realize that might not be
>immediately too convenient since it would involve renaming
>functions and files and ... sigh.
>
[MK] No, I like those three letters :P. If we want to change that we
will have to pickup some other meaningless three letters to use as a
prefix. One three-letter acronym is as good as any other three-letter
acronym, as long as you know what it stands for.

>
>
>page 6, I think you meant "intermittent" rather than "intermediate"
[MK] I probably did. Well at least I've got the first 6 letters right.
>
>Make the requirements a bullet/number list?  It would make it easier
>to see what all will be in the result.
[MK] ok will do in the next version
>
>paragraph 4.1, the last sentence is too vague.
[MK] Looks ok to me. How would you phrase that differently?
>
>paragraph 4.4, third sentence: is this invisible to the application
>until failure?
[MK] Yes it is invisible.=20
>
>paragraph 4.5, this would seem to imply there is no _read method for
>message available on the endpoint, which would seem to be a missing
>component.  I'm guessing this functionality is available through
>nfx_select()?.  Might mention that specifically somewhere.  Probably
>seems obvious to you, but there will always be someone that is new to
>the scene.  There is a weird sort of out-of-API set of functions that
>are necessary to use this API which maybe should be in the API, like
>nfx_select and rmc_init_ex [see comments below] and others.
>
>Otherwise, every single application has to implement the same
>
>for() { nfx_select() }
>
>loop.  More complicated apps will want to do that, but simpler apps may
>just want to utilize a _read method that already implements that.
>Tests are one such example, but it is really needed for completeness.
>One should be able to set blocking or non-blocking, but we can probably
>skip that; make it blocking only, subject to timeout of course.  If
>someone wants non-blocking, they can use select.
[MK]=20
There is already utils_send() for trivial synchronous cases like shells
or tests. Every other application has to implement select loop, making
this task easier is another story and out of scope here.=20

>
>
>page 10
>
>struct timeval open_tmo
>
>Perhaps it's not the scope of this document, but a programmer would
want
>to know what the interactions for timeouts might be, like does RMC
>and/or this API use any signals that might interfere with the
>application, etc.
[MK] There are no additional signals introduced, I didn't see the need
to make this explicit. The RMC uses SIGALRM which must be mentioned
somewhere in RMC design doc.

>
>page 13
>
>There has to be a server_close function just like there needs to be a
>client_close function for completeness.  One use is in signal handlers
>or post signal handler code; I assume that calling client_close will
>cause deallocation callbacks to be invoked for all outstanding memory.
[MK]=20
There will be one when we need it. So far in our code there have not
been any use case for server_close function, and I am not in favor of
adding code just for completeness.
>
>page 18
>
>I feel strongly that rmc_init_ex() should be handled by the API.
>Because libraries use RMC "behind the scenes", it's isn't reasonable to
>have this added to every app.  It should be quite trivial to handle
>this in the API somewhere in either the client or server init functions
>since one of those always has to be called first, yes?  I realize that
>it wont' necessarily know the "real" application name, but it isn't
>actually necessary to know that anyway.  pm might need to know in the
>case of daemons it controls, but otherwise a unique arbitrary string
>should suffice.  The API can check to see if it needs to call it and
>take care of it if it hasn't been called already.

[MK] That will require additional parameters for each rmc_client_init()
or rmc_server_init() that are used only once, which does not look right.
I can make sure the init functions return failure if rmc_init_ex() was
not called, that should take care of your concern.


>
>
>
>Cheers,
>
>a
